In the mobile domain, a service (e.g., a social networking web service, financial web service, news service, etc.) can push notifications to a corresponding application on a client device (e.g., a smart phone). Often, a mobile platform will act as an intermediary between a service and a client device, and will impose rules or restrictions on how the service communicates with the client device. A communication channel that allows push notifications to be sent from a service to a client device can be referred to as a push channel. A platform that enables a push channel typically requires the device and service to authenticate themselves with the platform. The complexities of device authentication can be hidden from the application by a push client stack on the device. However, the service authentication needs to be handled by the service directly, which results in additional cost and development effort. This makes it difficult for existing services or new services to adapt to the requirements of authentication, resulting in slower adoption of the platform.
Although authentication provides some measure of security, it also can be restrictive. In fact, the utility of many services (e.g., social networking services) depends on openness and ease of communication, which can be restricted by requiring authentication. In addition, for authentication to be reliable, a secure communication protocol is required.
Proxy services can be used to bridge the gap between platform servers that require a secure protocol for client device data transmission, and services that prefer to use more open protocols (such as ordinary, or non-secure, Hypertext Transfer Protocol (HTTP)). In the example shown in FIG. 1, a proxy service 100 enables communication between platform server 110 and service 120 by communicating with platform server 110 via a secure protocol (HTTPS) and communicating with service 120 via ordinary HTTP.
The use of proxy services introduces several problems. One problem is increased latency: the introduction of a proxy service as an intermediary can cause communication delays by introducing additional steps in the process of communication between platform servers and other services. Another problem is that a proxy service will tend to become a bottleneck as another service adds features that it wishes to expose to particular resources on the other side of the proxy service. This is because as new features are added, the proxy service must adapt to allow communications that enable the new features. Use of proxy services also may expose a user to additional security risks, because while the service the user wants to receive notifications from may be reliable, the proxy service may not be.
Representational state transfer, or REST, refers to a set of web services design principles that focus on uniform resource identifiers (URIs), HTTP, and other non-proprietary formats and protocols to provide web services. “RESTful” services employ REST design principles and tend to have less dependence on middleware, instead providing data in a more standard format that is easier for different applications to work with. Examples of RESTful web services include Twitter, Facebook and gMail.
Because of the increasing popularity of REST design in web services, applications that can work effectively with RESTful web services are increasingly desirable.
Whatever the benefits of previous techniques, they do not have the advantages of the techniques and tools presented below.